A server receiving numerous requests for resources within a brief period of time must be highly efficient in generating responses if the server is going to fulfill the requests within an acceptable period of time. One illustrative context where this problem arises is in connection with Enhanced Television (“ETV”). In the ETV context, typically a video production is distributed to numerous client applications. The video production has associated with it one or more enhancing resources that may be selected by a viewer of the video production. Conventionally, the enhancing resources are made available to the viewer by including an identifier of the resource in the video production. The viewer's client platform, e.g., a set-top box or computer, extracts the resource identifier and provides an indication to the viewer that enhancing resources are available. If the viewer selects the resource, a request is sent with the client application resident in the viewer's client platform. Frequently in the ETV context, numerous client applications each send requests contemporaneously. This aspect is typically present when, for instance, the video production is broadcast and each viewer becomes aware of the availability of the enhancing resource from the broadcast video production virtually simultaneously. It would thus be desirable for operators of servers receiving numerous simultaneous requests for server efficiency to be improved.
Unfortunately, conventional servers are not highly efficient. For instance, when a conventional HTTP server,  receives a request for a uniform resource identifier (‘URI’) it first parses the request, then parses header lines in the request. Next, the HTTP server applies a rewrite mapping process that transforms an external name for the resource (in the URI) to an internal name used for locating the resource and generating the response. Conventional modules for performing the rewrite mapping are powerful and flexible, but obtain this power and flexibility only through computational expense. After the HTTP server derives an internal name of the resource it must generate the response (by retrieving the associated file and/or running executable code) as well as generating headers for the response. If a request for the same resource, were to arrive at the server an instant later, a conventional server would repeat the foregoing steps. In a context where there are numerous simultaneous requests for the same set of resources, conventional server processing is needlessly redundant and inefficient.
Another type of conventional server is a caching proxy server. A caching proxy server is a conventional server which stores locally (or at least more locally) to a client certain resources that are requested from hosts on a data network, typically the internet. In this way a caching proxy server reduces response time by reducing or eliminating time lags introduced by having to retrieve the resource from a remote host, that may only be available through a slow or congested network connection. However, the caching proxy server does not reduce that component of total response time that is attributable to processing at the sever; a conventional caching proxy must flow through all of the intermediate states as any other server in generating a response. For example, a caching proxy server retains the inefficiencies of a conventional HTTP server in redundantly performing the mapping from an external name to an internal name for repeatedly-requested resources. Indeed, where delays in response time are introduced not from network lags, but from the sheer request volume at the server, a caching proxy server may provide no noticeable benefits to the user whatsoever.
Accordingly, it would be desirable for there to be a means for reducing redundant processing in serving repeated requests for a resource.